Cumulated content of eOrdering meetings

Working Group meeting

Date: 20/04/2023
Participants: Natalie Muric, Thomas Pattersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discuss eOrdring module.

Discussion:

The working group discussed and defined the following eOrdering concepts:

epo-ord:AllowanceChargeInformation: Information about discounts and fees imposed.

epo-ord:DocumentAllowanceInformation: Information about the discounts imposed at the Document level. Additional Information: Document level refers to the complete document, such as: Order, Despatch Advice, Invoice.

epo-ord:LineChargeInformation: Information about the fees imposed at the Document Line level. Additional Information: Document Line level refers to each line in a document, such as: Order Line, Despatch Advice Line, Invoice Line.

epo-ord:PriceDiscountInformation: Information about the allowances imposed on the Price.

epo-ord:ContractInformation: Information about the Contract.

epo-ord:DeliveryTerm: Conditions and stipulations applying to the delivery of goods, services and works. Additional Information: Delivery terms identifier can normally be Incoterms accompanied by the description of specific conditions related to the delivery.

epo-ord:DocumentChargeInformation: Information about the fees imposed at the Document level. Additional Information: Document level refers to the complete document, such as: Order, Despatch Advice, Invoice.

epo-ord:LineAllowanceInformation: Information about the discounts imposed at the Document Line level. Additional Information: Document Line level refers to each line in a document, such as: Order Line, Despatch Advice Line, Invoice Line.

epo-ord:LineChargeInformation: Information about the fees imposed at the Document Line level. Additional Information: Document Line level refers to each line in a document, such as: Order Line, Despatch Advice Line, Invoice Line.

epo-ord:OrderLine: Details concerning a given unit of goods, services or works requested in the Order. Additional information: In general, an Order Line contains the Quantity and Price of the goods, services and goods requested in the Order. However, in certain cases, the Price may not be known, as the Price may fluctuate from one day to the other.

epo-ord:Order: A formal request of the Buyer to the Seller specifying the goods, services or works to be delivered. Additional Information: A Buyer submits an Order for delivery of goods, services or works to a Seller.

epo-ord:Originator: A Role of an Agent that expresses the needs to trigger the Procurement. Additional Information: The Originator is often the end-user or the Beneficiary.

epo-ord:OriginatorInformation: Information about the Originator of the Order.

epo-ord:TaxInformation: Information about the duty imposed (this definition needs to be discussed further)

epo-ord:TaxInformationSchema: Information about the type of duty.

Working Group meeting

Date: 28/03/2023
Participants: Natalie Muric, Wim Kok, Christian Mondini Consorzio, Pietro Palermo, Ivan Willer, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discuss all the information objects with respect to the order line, order header level, price and complete the relationships.

Discussion

The WG continued to discuss the Order diagram with respect to Peppol Order transaction 3.2 (T01) to be sure that they are compatible.
It was noted that, there is a reference to a Catalogue in header level but not in Catalogue line level.

  • epo-cat:Line object is created to refer to the Catalogue line (epo-cat:Catalogueline).

+CCEEEKWlVUEAQYAADhjyAGEEEIIWUZWEQQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANYCBBgAAAAAAADWAgQYAAAAAAAA1gIEGAAAAAAAANaCgQATQgghhBBCCCFnOf8PQQskdWsPprEAAAAASUVORK5CYII=

  • epo:hasCatalogueItemId is the seller Id:

AAAAAElFTkSuQmCC

  • epo-cat:hasExternalSpecification association is added between epo-cat:Item and epo:Document

wFJKFL61+XFXAAAAABJRU5ErkJggg==

  • epo-cat:Item has epo-cat:hasItemclassification relation which refers to at-voc-new:unspc

  • at-voc-new:unspc needs to be aligned with eCatalogue in order to choose the codelist.

  • VAT:

    • In epo-cat:item, there is epo-cat:hasVATRate

    • There is epo-cat:asVAtCategory

AcsuCNf2M8S0AAAAAElFTkSuQmCC

  • epo-ord:TaxInformationSchema object is added to order line class with epo-cat:hasPercentage:xsd:decimal property

FihwAAAABJRU5ErkJggg==

  • Additional Item Property

    • There is epo-cat:ItemDescription

4fHMdiMTChfYgAAAAASUVORK5CYII=

  • Serial identifier:

    • epo-cat:hasSerialId relation is created between epo-cat:Item and identifier in Catalogue module

  • Price:

    • epo-ord:OrderLine has a price.

    • epo-ord:PriceDiscountInformation object is added

    • epo-cat:Price has Price Allowance Information

nAc76tGon7z8sgAPABIgwAMAoCGEeGEmXlVhlpY6eFUP7wR4ADBuAjwAAGaqhzzq4BYAMF4CPAAAZoqDHnUwCwAYLwEeAAAAAIyYAA8AAAAARkyABwAAAAAjJsADAAAAgBET4AEAAADAiAnwAAAAAGDEBHgAAAAAMGICPAAAAAAYMQEeAAAAAIyYAA8AAAAARkyABwAAAAAjJsADAAAAgBET4AEAAADAiAnwAAAAAGDEBHgAAAAAMGICPAAAAAAYMQEeAAAAAIyYAA8AAAAARkyABwAAAAAjJsADAAAAgBET4AEAAADAiAnwAAAAAGDEBHgAAAAAMGKNAE8ppZRSSimllFJKKTW++v8Bl1DwQO7nfrcAAAAASUVORK5CYII=

Action:

  • Provide definitions for Post Award Concepts (attributes and properties).

Working Group meeting

Date: 23/03/2023
Participants: Natalie Muric, Christian Mondini Consorzio,Najeh Hajlaoui, Wim Kok, Pietro Palermo, Thomas pettersson, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discussion

The WG continued to discuss the Order diagram with respect to Peppol Order transaction 3.2 (T01) to be sure that they are compatible.

The current approach to assessing the completeness of the ePO model with respect to PEPPOL requirements involves determining whether the following requirements are already covered by ePO. If they are, the WG will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the PEPPOL requirements, while the sub-bullets indicate their mapping to ePO.

  • cac:PaymentTerms

    • epo-ord:Order has epo-ord:hasPaymentTerm property

LRVEUvdk7jGktMgiCIMjwB8ggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjQXIIAiCII0FyCAIgiCNBcggCIIgjcVBBkVRFEX73f8HtsWDBxxUVtIAAAAASUVORK5CYII=

  • cac:AllowanceCharge:

    • epo-ord:AllowanceChargeInformation is created exists

  • cbc:AllowanceChargeReason:

    • epo-ful:hasAllowanceChargeReason exists

  • cbc:MultiplierFactorNumeric

    • epo-ord:AllowanceChargeInformation has epo-cat:hasPercentage property

h806GNXtP3bqgAAAABJRU5ErkJggg==

  • cbc:Amount and @currencyID

    • epo-cat:Price has Net Monetary Value which has a currency

gP4oGLeM864TQAAAABJRU5ErkJggg==

  • cac:TaxCategory, cac:TaxScheme. Tax information to be discussed in document level

  • cac:AnticipatedMonetaryTotal: it is an estimation of buyer, epo-cat:hasPercentage Anticipated is on order level Order total amount class is created: to add all amounts: which are all in the header level.

AU5nlhNCPPpbAAAAAElFTkSuQmCC

Order Allowance Charge class is created: it was noted that Discount and Allowance is the same

  • epo-ord:AllowanceChargeInformation object is created, and it generalizes the following objects, epo-ord:DocumentChargeInformation, epo-ord:DocumentAllowanceInformation epo-ord:LineChargeInformation, epo-ord:LineAllowanceInformation, epo-ord:PriceAllowanceInformation, epo-cat:ChargeInformation.

  • epo-ord:TaxIformation object is created with epo-cat:hasPercentage property

  • epo-cat:hasTaxScheme is created between epo-ord:TaxIformation and at-voc-new:tax-scheme

  • epo-cat:hasTaxCategory is created between epo-ord:TaxIformation and at-voc-new:tax-scheme and at-voc-new:tax-category

  • epo-ful:hasAllowanceChargeReason relation is added between ord:AllowanceChargeInformation and at-voc-new:allowance-charge-reason

1KfamZqOA5OAAAAAElFTkSuQmCC

Actions:

  • Discuss and investigate if we want to add the aggregates, mainly cac:AnticipatedMonetaryTotal.

  • Discuss the new naming for Catalogue and fulfilment e.g., tax-category instead of charge-category.

Working Group meeting

Date: 23/02/2023
Participants: Ahmad Abid, Laszlo Ketszeri, Natalie Muric, Wim Kok, Pietro Palermo, Thomas pettersson, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discussion:

The WG continued to discuss the Order diagram with respect to Peppol Order transaction 3.2 (T01) to be sure that they are compatible.

  • cac:Delivery

    • We have epo-ord:DeliveryInformation with epo-ful:hasShippingMark attribute.

LuicSclpO8OhnMohJ+0MuemvmKHew5Bxnty5fZu1r1ghdiqCIEg1aV++nB3r64OM84KETBWyDv1LhyAIkhZTxJBxDTB3LoIgSNYUEcgYQZCHLkXkvpYxAAA8KEDGAABQACBjAAAoAJAxAAAUAMgYAAAKAGQMAAAFADIGAIACABkDAEABgIwBAKAAQMYAAFAAIGMAACgAkDEAABQAyBgAAAoAZAwAAAUAMgYAgAIAGQMAQAGAjAEAoABAxgAAUAAgYwAAKACQMQAAFADIGAAACgBkDAAABQAyBgCAApCQMYIgCFKfEP8PggmozIQCn50AAAAASUVORK5CYII=

  • adms:identifier relation is added between dct:location and adms:Identifier

90KLetBU14L5yU2RP162NEjeF3N9+t5IaZD8CvwPS0eXiA4jmagAAAAASUVORK5CYII=

  • epo-ord:DeliveryInformation has a delivery period

s+it0D+WGPk34Vroy51yB4AAAAAASUVORK5CYII=

  • epo-ord:hasDeliveryDeadline property is added to epo-ord:DeliveryInformation epo-ord:DeliveryInformation

  • epo-ord:DeliveryTerm is created with two relations (epo-ord:specifiesGeneralDeliveryTerm, epo-ord:specifiesSpecialDeliveryTerm )

  • epo-ord:specifiesDeliveryTermLocation is created between epo-ord:DeliveryTerm and dct:Location

welDORsTK9jDwAAAABJRU5ErkJggg==

Actions:

  • 02 March, eFulfilment meeting:

    • Discuss shipping mark

    • Discuss the concept of ReceivingAdvice

  • In order to provide a glossary that also includes external relations to Concepts from other modules, we need to enable a flag in model2owl script [Meaningfy].

Working Group meeting

Date: 21/02/2023
Participants: Alba Colomer, Marc Christopher, Natalie Muric, Pietro Palermo, Sellitto Giovanni Paolo, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discussion:

epo:AccountingCustomer

  • epo:AccountingCustomer is redefined: it is not a party, it is just an office receiving invoices.

  • order invoice class is created: it contains the main objects and relation between order and invoice:

    • Note: Invoicee is not a different organization from the buyer. They are two offices for the same organization.

    • Invoicee needs contactPoint and endpoint (channel)

    • epo:hasEndpointIdentifier relation is defined between epo:Channel and epo:Identifier

    • epo:exposesInvoiceChannel relation is created between epo:Buyer and epo:Channel

7O7G9tQWwB0EQBEEQBEEQBEGjKgn35OSeLTnBg0Kh2l8u1APYgyAIgiAIgiAIgqAWyG30USjU+NQoCWAPgiAIgiAIgiAIghiFzT4KhRqPGiUB7EEQBEEQBEEQBEEQBEHQCApgD4IgCIIgCIIgCIIgCIJGUAB7EARBEARBEARBEARBEDSCAtiDIAiCIAiCIAiCIAiCoBEUwB4EQRAEQRAEQRAEQRAEjaAA9iAIgiAIgiAIgiAIgiBoBAWwB0EQBEEQBEEQBEEQBEEjKIA9CIIgCIIgCIIgCIIgCBpBAexBEARBEARBEARBEARB0AgKYA+CIAiCIAiCIAiCIAiCRlAAexAEQRAEQRAEQRAEQRA0ggLYgyAIgiAIgiAIgiAIgqARFMAeBEEQBEEQBEEQBEEQBI2gAPYgCIIgCIIgCIIgCIIgaAQFsAdBEARBEARBEARBEARBIyiAPQiCIAiCIAiCIAiCIAgaQQHsQRAEQRAEQRAEQRAEQdAICmAPgiAIgiAIgiAIgiAIgkZQAHsQBEEQBEEQBEEQBEEQNIIC2IMgCIIgCIIgCIIgCIKgERTAHgRBEARBEARBEARBEASNoAD2IAiCIAiCIAiCIAiCIGgEBbAHQRAEQRAEQRAEQRAEQSMoAvZQKBQKhUKhUCgUCoVCoVAo1GiU1P8PM7kxuF7yAs8AAAAASUVORK5CYII=

  • A new model for Invoice is created.

    • epo-ful:Invoicer changed to epo-inv:Invoicer and moved to Invoice model

XAAAAAElFTkSuQmCC

  • WG discussed the originator, consignee and beneficiary (ordering roles class)

    • epo-ord:Beneficiary is deleted .

    • Originator definition is added: The party who will eventually receive and consume the goods and on whose behalf the buyer makes the purchase

wPXvlJvvq6qCwAAAABJRU5ErkJggg==

  • epo:hasToolAccessUrl is created between epo:Channel and epo:AgentInRole and deleted from epo:accessTerm

j9OL02KqNoaNQAAAABJRU5ErkJggg==

  • epo:isProcurementDocumentRestricted: xsd: boolean property is created in epo:AccessTerm

mJUpfi5gAAAABJRU5ErkJggg==

Working Group meeting

Date: 09/02/2023
Participants: Fred van Blommestein, Alba Colomer, Wim Kok, Laszlo Ketszeri, Natalie Muric, Pietro Palermo, Sellitto Giovanni Paolo
Model editor: Eugeniu Costetchi
Note editor: Jana Ahmad

Agenda

  • Define epo:Project and epo:ProcurementProject

  • Continue on eOrdering open discussion

    • Goal is to ensure completeness of the current model

    • The current method of checking and depicting if the ePO model is complete regarding PEPPOL requirements is by having diagrams which clearly depict the necessary elements.

    • To be continued from ac:BuyerCustomerParty

Discussion

The WG discussed the definition of procurement project that links together the call for tender with an element that is not present in the Call for Tender but that is overarching multiple calls for tenders. It links together that are very different but are developed in the context and contribute to the same value. Note, Order refers to a project

rGxwAAAABJRU5ErkJggg==

The WG continued to discuss the Order diagram with respect to Peppol Order transaction 3.2 (T01) to be sure that they are compatible.

The current approach to assessing the completeness of the ePO model with respect to PEPPOL requirements involves determining whether the following requirements are already covered by ePO. If they are, the WG will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the PEPPOL requirements, while the sub-bullets indicate their mapping to ePO.

  • ac:BuyerCustomerParty

    • Order specifies a Buyer

    • We have Buyer party electronic address (cbc:EndpointID)

+AnGqd8LXYYQdAAAAAElFTkSuQmCC

  • Note: Order has always one buyer

  • Buyer has contactPoint and contactPoint hasInternetAddress

F+vJlnOFOa7GgAAAABJRU5ErkJggg==

  • A role has a channel

    • epo:Channel is added class Order

    • epo:exposesChannel relation is created between epp:AgentInRole and epo:channel{}y

      • epo:Channel has two properties

        • po:exposesChannelhasAddress property

        • epo:hasEndpointIdentifier

    • Consider creating a subclass AdHocChannel.

    • epo:hasEndpointIdentifier relation between epo:channel and adms:Identifier

AUzmr1VW3V+HAAAAAElFTkSuQmCC

  • cac:Party:

    • Is a party or agent in Order model (e.g., buyer, seller)

    • Organization which is a type of agent can have identifiers.

    • epo:hasLegalIdentifier relation is created between The eop:Organization and epo:Identifier

    • epo:hasTaxIdentifier relation is created between The eop:Organization and epo:Identifier

  • We have: Party name, Postal address, Party identification (adms:identifier)

  • cac:PartyTaxScheme:

    • TaxScheme class is created

    • epo-ord:TaxInformation Object is created

    • In epo:Identifier we have hasScheme

Actions

  • We need to discuss urgently access term and channel [OP and Meaningfy]

  • In order to align with Core Voc, it means we need to add cv:LegalEntity and org:FormalOrganization between org:Organization and epo:Business.

Working Group meeting

Date: 09/02/2023
Participants: Alba Colomer, Wim Kok, Ivan Miller, Natalie Muric, Carlos Mazo, Pietro Palermo, Thomas Pattersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

  • Continue on eOrdering open discussion

    • Goal is to ensure completeness of the current model

Discussion

The WG discussed the Order diagram with respect to Peppol Order transaction 3.2 (T01) to be sure that they are compatible.

Methodology:

The current approach to assessing the completeness of the ePO model with respect to PEPPOL requirements involves determining whether the following requirements are already covered by ePO. If they are, the WG will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the PEPPOL requirements, while the sub-bullets indicate their mapping to ePO. * cac:QuotationDocumentReference Quotation considered to be an offer In offer class: relations between to be renamed between epo:TechnicalOffer, epo:FinancialOffer and procurement-object epo:Tender epo:OfferIssuer role is created which is the role of agent who distributes an offer epo:distributesOffer relation between offer and offerIssuer is created ** Offer objet is added to document class (to be decided if it should stay on the core or only in offer module)

yLITJ8rwlGMAAAAASUVORK5CYII=

  • Note: Document provides the monetary value and the details to fulfill the requirements set out in the procurement document or request of offer.

    • cac:OrderDocumentReference

  • epo-ord:OrderDocument is created in order class

  • epo-ord:refersToOrder (reflexive relation) is added to epo:order

  • Epo-ord:supersedesOrder is moved from epo-ord:order to epo-ord:OrderDocument

  • epo-ord:instantiateOrder relation is created between epo-ord:order and epo-ord:OrderDocument

PHsQInQIxQi1IOcrM0YbMKojuhStFxAhdATHCnOA+PInuBkAXQIwwJ4QPUKKbAdAFECMAAIADYgQAAHBAjAAAAA6IEQAAwAExAgAAOCBGAAAAB8QIAADggBgBAAAcECMAAIADYgQAAHBAjAAAAA6IEQAAwAExAgAAOCBGAAAAB8QIAADggBgBAAAcECMAAIADYgQAAHBAjAAAAA6IEQAAwAExAgAAOCBGAAAAB8QIAADg4ImRIAiCIIhvaTECAACA5v8DM+MSEox8WecAAAAASUVORK5CYII=

  • epo:ProcurementOrginater object is deleted

    • cac:OriginatorDocumentReference

  • epo:OriginatorRequest Document is created in Document hierarchy and put it in order level. epo:OriginatorRequest is the document in which the originator describes his needs

  • epo-ord:concernsOriginatorRequest relation is created between epo:GeneratorInformation and epo:ProcrumentOrginater

xxEyqzd9usjAAAAAElFTkSuQmCC

  • Document type enumeration is added to the document.

  • Note: a document with order type create a document type

wPKVPKel8rgGAAAAABJRU5ErkJggg==

  • cac:AdditionalDocumentReference

    • It’s a document with document type and other properties such as issue date and issue time, id .

  • cac:Contract

    • We have epo:Contract and epo-ord:ContractInformation in order level

13BMNy466auBhEIgiAIgiAIgrpTABEIgiAIgiAIgtougAgEQRAEQRAEQW0XQASCIAiCIAiCoLYLIAJBEARBEARBUNsFEIEgCIIgCIIgqO0CiEAQBEEQBEEQ1HYBRCAIgiAIgiAIarsAIhAEQRAEQRAEtV0AEQiCIAiCIAiC2i6ACARBEARBEARBbRdABIIgCIIgCIKgtgsgAkEQBEEQBEFQ2wUQgSAIgiAIgiCo7QKIQBAEQRAEQRDUdgFEIAiCIAiCIAhquwAiEARBEARBEAS1XQARCIIgCIIgCILaLoAIBEEQBEEQBEFtF0AEgiAIgiAIgqC2CyACQRAEQRAEQVDbBRCBIAiCIAiCIKjtAohAEARBEARBENR2ERCBYRiGYRiGYRhuh3MQgSAIgiAIgiAIaqf+P0WeWRwuVgQUAAAAAElFTkSuQmCC

  • cac:ProjectReference

    • epo:ProcurementProject and epo:project are created in order level.

    • epo-ord:order refers to project

    • Relation is created between epo:Project and epo:Identifier

8PGoirWmMFnuEAAAAASUVORK5CYII=

Action:

  • Add proper definition for all information Hubs

  • In offer class: relations between to be renamed between epo:TechnicalOffer, epo:FinancialOffer and procurement-object epo:Tender

  • We need codes for https://docs.peppol.eu/poacc/upgrade-3/2022-Q4/codelist/UNCL1001_101/ for at-voc-new:document type.

  • Decide whether epo:ProcurementProject should be a ProcurementElement or not

B7vFi5lW3Q5UAAAAAElFTkSuQmCC

Working Group meeting

Date: 26/01/2023
Participants: Natalie Muric, Svante Shcubert, Pietro Palermo, Peter, Thomas Pettersson, Ivan Weller
Model editor: Eugeniu Costetchi
Note editor: Jana Ahmad

Agenda

  • eOrdering open discussion

    • Goal is to ensure completeness of the current model

Discussion

The WG discussed the Order diagram with respect to Peppol Order transaction 3.2 (T01) to be sure that they are compatible.

Methodology:

The current approach to assessing the completeness of the ePO model with respect to PEPPOL requirements involves determining whether the following requirements are already covered by ePO. If they are, the WG will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the PEPPOL requirements, while the sub-bullets indicate their mapping to ePO.

  • ubl:order

    • order only diagram renamed to order

    • epo-cat:lineSet changed to eop-cat:PostAwardObject

B+GIypGNZCU6AAAAAElFTkSuQmCC

  • identifiers : (cbc:CustomizationID, cbc:ProfileID, cbc:ID)

    • epo:hasID, epo:hasPprofileID and epo:hasCustomizationID object properties are added to epo-cat:PostAwardObject and defined

wDSzYPpmN96SAAAAABJRU5ErkJggg==

  • cbc:SalesOrderID

    • ope-ord:hasSalesID: this relation should be created on an object of type Offer when it is modeled

    • Note: in Sales order, the order can be sent from seller to buyer to sign it.

  • cbc:IssueDate, cbc:IssueTime

    • Time is at the metadata level.

    • time and date properties should be added

    • A link between eop-Order to epo-Document should be added

    • Crate relation between eop-Document and eop-cat:PostAwardObject

      • Link the document “metadata layer”with the content of document

  • cbc:OrderTypeCode: for Order type:

H9tnVisnSEdCgAAAABJRU5ErkJggg==

  • Cbc:note

    • epo:hasAdditinalinformation is added to eop-cat:postAwardObjec

  • cbc:DocumentCurrencyCode

    • Mapped to epo:MonetaryValue.

    • epo:oderLine has price which is a MonetaryValue

  • cbc:CustomerReference

    • eop-ord:hasChttps://docs.peppol.eu/poacc/upgrade-3/syntax/Order/cbc-CustomerReference/[ustomerReference] t is added to order object

  • cbc:AccountingCost

    • eop-ord:hasAccountingCost t is added to order object

weHT0z2YE3AaAAAAABJRU5ErkJggg==

  • cac:ValidityPeriod:

    • eop-cat:PostAwardObjec has (epo:hasValidatyPeriod) relation with epo:Period class

j+WpHcypzL6sAAAAABJRU5ErkJggg==

To be continued with “cac:QuotationDocumentReference” - https://docs.peppol.eu/poacc/upgrade-3/2022-Q4/syntax/Order/tree/

Ideas for future development:

  • Generate automatically an application profile listing all properties for a Create a table that contains all the properties for all the concepts in the Order phase.

  • There is a need for mapping UBL , UNCFACT and ePO

  • There is a digital gap between TC440 and ePO Work GRoup

    • Need to extract a worksheet from the class diagram and just have the list of classes and properties, in the likes of tabular application profile definition. This shall include the inherited properties as well.

Working Group meeting

Date: 12/01/2023
Participants: Jana Ahmad, Natalie Muric, Giampaolo Sellito, Peter, Thomas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discussion

eContract

  • WG discussed the General and Specific contract condition data model.

  • Question: Why not limit to simply what is specified in eForms rather than a fully fledged contract model?.

    • Because the main purpose is to cover the needs of eForms.

  • proposal to align with OCD

  • WG will not discuss Contract Performance till March 2023, but they will discuss mainly what is necessary to represent Contract Modifications covered by the eForms

    • General conditions

    • Specific conditions

    • Contractor

  • Procurement with the Contract in the Center is a valid frame of reference / modelling perspective.

  • Question: What about the Contract Performance data?

    • It is hard to standardise. Only generic properties and concepts can be modelled. For example think of Service Level Agreement (SLA), which is an attachment to a contract.

    • There is no need to standardise service level agreement

eOdering order only

  • The response is part of the order model and shall be included in order to support the data exchange processes and choreography.

  • Order Only and Ordering (with Response) are artificial separations in PEPPOL like diagrams in EPO provide views on the same (whole) model.

  • Order response : information about what is the response

  • Order and order response are almost the same

  • Create an issue in github about data models

  • There is a need to develop the core but developing modulus is not a major release.

eOrdering and response

Revise eFulfillment

Despatch advice concepts

  • All information is in line level

  • eCMR and Dispatch advice should have relation

  • eCMR should link to order

  • eCMR might refer to the dispatch advice (as a barcode and URI) as the DESADV might refer to the eCMR.

  • Shipment during the delivery or despatch of the goods is accompanied by an eCMR document as it had been ratified by the majorities of the MS.

  • Consignment consists of TransportHandlingUint (THU)

  • THU is not the Package

    • THU is the container

    • Package is the Pallet or the box

  • OP does not need to take everything on despatch from PEPPOL.

  • To be modelled

Feedback

Bullet points extracted from an Email on 02/11/2022

  • Item Property. Add “ValueQualifier”, Standardized and predefined classification of items properties

  • Shipment. Addition in TransportHandlingUnit

    • “Handling unit type”, The type of packaging that represents the handling unit, such as box, pallet, container etc.

    • “Handling unit shipping marks”, Free-form description of the marks and numbers on a transport unit or package.

    • “Measurement dimensions”,

      • “Attribute identifier”, Code to indicate if the measure is gross weight or gross volume.

      • “Measure”, incl unitcode

  • “Package” within this handling unit

    • “Package identifier”

    • “Packaging type code”, The type of packaging used, such as box, pallet, container etc.

Action point:

  • Update html version of eOrdering (ordering and response) and send for revision.

  • Model the Advanced despatch from PEPPOL[here] + using diagrams from the meeting for guidance

  • Harmonise across modules (order/catalogue/despatch and their lines + the information hubs that may associate with some or all of them)

eOrdering meeting

Date: 01/12/2022
Participants: Veit Jahns, Wim Kok, Natalie Muric, Peitro Palermo, Thomas Petterson, Svante Schubert
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Feedback for eOrdering model

  • Order-delivery-invoice relationship

Discussion

Feedback for eOrdering model

Order-delivery-invoice relationship

Problem statement

In the order head level you find the “Delivery location” and the “Internal party to whom the goods are delivered (beneficiary)”. And also the expected delivery date.
On the line level you can NOT define a different Delivery location and the Internal party. You may have different delivery dates though.
This way it’s not too complex.
In Peppol (and as it’s implemented in Sweden), if you need to place an order to a different “Delivery location” and “Internal party to whom the goods are delivered”, you just place another order.
It’s very straightforward.

In the ePO-meetings the designed structure seems to me to be much too complex as “Delivery location” and “Internal party to whom the goods are delivered” is also on the order line.

NOTE that the invoice only refers to ONE order and ONE “Delivery location” and ONE “Internal party to whom the goods are delivered” and ONE delivery.
This means that the proposed complexity will also have implications to the way invoices must be implemented.

Discussion

  • Date and Time is not in DeliveryInformation. Maybe DeliveryInformation is not the proper word.

  • DeliveryInformation contains the Delivery Location details, the Beneficiary and the Consignee.

  • This is not only about DeliveryInformation, but also at a different level, like Project ID, Contract.

  • Discuss Cardinalities for Order - Despatch - Invoice relations:

    • In PEPPOL a DespatchAdvice can refer to multiple Orders. (0..n • cac:OrderReference in Peppol Despatch Advice transaction 3.1 (T16))

    • In PEPPOL an Invoice can refer to only one Order.

    • Invoice refers to a DespatchAdvice, and the DespatchAdvice refers to the Order.

wEGYbG1Msr9qQAAAABJRU5ErkJggg==

  • In Italy the Contract and the Lot are at the Line level.

Solution 1 - subclasses

Create subclasses of Order: Simple Order and Advanced Order and subclasses for Order Line: Simple Order Line and Advanced Order Line

Pros

  • Ensures unambiguous model

  • Accommodates two ways of indicating the address

  • Maintains interoperability

Cons

  • Increases the model complexity by adding four new classes: 2 on the Order and 2 on the OrderLine

Class diagram
B6I9taKdhVbbAAAAAElFTkSuQmCC
Instance diagrams
g97cD84XgAAAABJRU5ErkJggg==
93YTyBAAAAAAOUJ4AAAAAwAHKEwAAAAA4QHkCAAAAAAcoTwAAAADgAOUJAAAAABz44f3IkAAAAAAAX0d5AgAAAAAHKE8AAAAA4ADlCQAAAAAcoDwBAAAAgAOUJwAAAABwgPIEAAAAAA5QngAAAADAAcoTAAAAADhAeQIAAAAAByhPAAAAAOAA5QkAAAAAHKA8AQAAAIADlCcAAAAAcIDyBAAAAAAOUJ4AAAAAwAHKEwAAAAA48MP74XcCAAAAAHwd5QkAAAAAHPgf377Rg7nGoC4AAAAASUVORK5CYII=
Solution 2 - granular delivery specification

Leave the delivery address only at the Order Line level.

Pros

  • Allows for granular delivery location (and possibly other info) specification

  • Maintains interoperability ====== Cons

  • Differs from PEPPOL

  • Possibly a bit model burdensome for implementers to handle (but not really).

Instance diagram
Gli0iYiIiIhOAIs2EREREdEJ+N+6dg1ERERERGRfLNpERERERCeARZuIiIiI6ASwaBMRERERnQAWbSIiIiKiE8CiTURERER0Ali0iYiIiIhOwP8DaoHL5mo5SvMAAAAASUVORK5CYII=
Solution 3 - coarse delivery specification

Keep the delivery address only at the Order (header) level.

Pros

  • Clean approach

  • Aligned to PEPPOL

  • Maintains interoperability ====== Cons

  • Cannot satisfy the requirements of some Member States that need granular specification

Instance diagram
upu+nt3KX4AAAAASUVORK5CYII=
Solution 4 - ambiguous model

Keep the model ambiguous and rely instead on application profiles to reduce the ambiguity.

Pros

  • Models both approaches in a simplistic way ====== Cons

  • Bad modelling practice allows for the same information to be expressed in multiple ways/places.

  • Implementers will need an extra level of conflict/contradiction resolution.

  • Breaks interoperability.

Instance diagram
8GNYQ0AACpK4ehC9VMff8CJem5Q3dTHXwcMawAAAAAAfGBYAwAAAADgA8MaAAAAAAAfGNYAAAAAAPjAsAYAAAAAwIdDK78vCAAAAAAA8IZhDQAAAACADwxrAAAAAAB8YFgDAAAAAOADwxoAAAAAAB8Y1gAAAAAA+PAvGW+DAoRfpAYAAAAASUVORK5CYII=
Solution 5 - coarse delivery information, with “specificity to”
AxeaMrzeqCCCAAAAAElFTkSuQmCC

Doing a new instance example for this solution:

  • Copy from order sandbox diagram

Doing a new instance example with Contracts included:

  • Contract can also be at OrderLine.

  • A solution might be to create a hub class, ContractualInfo, that binds a Contract to Order and OrderLine.

QBKRigjnaDIbQAAAABJRU5ErkJggg==

  • Proposal to specify all the Concepts at the OrderLine level.- solution 2. If something is represented at the header level, then it must be because we can not represent it differently.

sgxBCiPZwRJQ5fuQg3Btrak+QRI8QQnSu59xrDgghhGgfriqcHYjfVFgd+saTPEj0CCFEx3rOOEOVEEKI9qJmdGMVXgQ6iUSPEEJ0LokeIYRocxI9GokeIYToXBI9QgjR5iR6NBI9QgjRuSR6hBCizUn0aCR6hBCic0n0CCFEm5PoEUII0emeM76LvBBCiPYTEMUXPwpA49eEEEK0N4keIYToAMaNf0fyljB+TQghRFuT6BFCiA5g3PgLIYQQnUSiRwghOoBx4y+EEEJ0kv8PbUX6USWTK0sAAAAASUVORK5CYII=

  • Also diagram at the concept level:

A90DDGQOM7cDAAAAAElFTkSuQmCC

  • This will be taken as homework and come to a conclusion.

  • The solution with the concept hubs is preferred.

  • This pattern should be applied to all the delivery messages.

eOrdering meeting

Date: 17/11/2022
Participants: Veit Jahns, Natalie Muric, Peitro Palermo, Thomas Petterson, Ivan Wiler
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Order-delivery-invoice relationship

In Sweden we have had e-business up and running in the public sector since the 1990’s. The first standard was in EDIFACT-format and was based on GS1 EANCOM. It was named SFTI/ESAP 6.
Later we have been adopting to Peppol. The complexity regarding the order-delivery-invoice is about the same. Of course we are using the standard Peppol BIS Billing 3 as the recommended invoice format.

In the order head level you find the “Delivery location” and the “Internal party to whom the goods are delivered (beneficiary)”. And also the expected delivery date.
On the line level you can NOT define a different Delivery location and the Internal party. You may have different delivery dates though.
This way it’s not too complex.
In Peppol (and as it’s implemented in Sweden), if you need to place an order to different “Delivery location” and “Internal party to whom the goods are delivered”, you just place another order.
It’s very straight forward.

In the ePO-meetings the designed structure seems to me to be much too complex as “Delivery location” and “Internal party to whom the goods are delivered” is also on the order line.

NOTE that the invoice only refers to ONE order and ONE “Delivery location” and ONE “Internal party to whom the goods are delivered” and ONE delivery.
This means that the proposed complexity will also have implications to the way invoices must be implemented.

Hi Thomas, as in the invoice we have the same reasoning to do: if we forsee a multiple relationship between order and delivery location 1:n in case one country decide not to have it, it will issue an usage specification to reduce cardinality to 1:1 remaining still compliant to the semantic model.

Putting in the model a 1:1 relationship, instead, will mean that countries with more complex environment (like Italy) have to use extensions to reach the desired result.

Discussion

Order-delivery-invoice relationship

Questions

  • How many invoices can correspond to an order?

    • Many (in Italy)

    • One (in Sweden)

    • One (PEPPOL)

  • How many orders can be covered by an invoice?

    • …

  • How many deliveries/dispatches can be done from an order?

    • …

  • How many orders can be covered by a delivery/dispatch?

    • …

Issues

  • Same relationship at the header and line levels leads to the problem of possibly conflicting information

    • In ordering

      • Delivery information

      • Discount information

      • Charge Information

    • In despatch

      • Shipment information

  • In despatch some information is mirroring order, how can this be reduced?

    • For example, item is described in the DespatchLine, isn’t it enough to make a reference to the order line?

Notes

In Sweden the delivery address is only at the header level.
If an italian order is sent to a sweden supplier there will be problems.

An order may specify some information at the Header Level or at Line Level, but NOT both at the same time.
A solution may be to create two subclasses: SimpleOrder and AdvancedOrder.

If delivery information is present at both line and header level, you choose whatever we want. But this solution might lead to multiple interpretations.

An Order will contain a Lot ID.

An invoice has a project reference and contract reference at the header level. In the line level there are no references to contract, project, order, despatch advice because an invoice to be as simple as possible in order to be accepted in every environment.

eOrdering meeting

Date: 03/11/2022
Participants: Natalie Muric, Thomas Petterson, Giampaolo Sellito, Ivan Wiler
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Order only model overview

Discussion

  • Starting by discussing the PEPPOL Order only use cases.

Use case 1

  • Last time we discussed the first use case from Order only - ordering of numbered items/articles.

5f4kRmij2F0z2AAAAAElFTkSuQmCC

  • We have an Order concept that is linked to an OrderLine. We can not have an OrderLine without specifying an item.

  • An OrderLine specifies a delivery by using the concept DeliveryInformation. The DeliveryInformation specifies a place of delivery and a place of storage.

  • The OrderLine specifies an Originator

  • The DeliveryInformation specifies a Beneficiary and a Consignee.

  • A Buyer and Seller are both specified at the level of Order.

  • The Order is invoiced to an Invoicee.

  • The Order can also specify a Despatcher.

Use case 2

  • This use case contains an order of free text articles.

  • A Validity Period is specified at the Order level.

  • The flow is the following:

    • The buyer creates the order with 2 different lines and items.

    • The seller receives the order.

Use case 3

  • An order of translation services.

  • Delivery location and period is specified.

  • The flow is the following:

    • The buyer creates the order with one line requesting translation between Swedish and Spanish.

    • The seller receives the order.

Use case 4

8HGeH0dfczVGQAAAAASUVORK5CYII=

  • From a modeling point of view there is no difference between Charge and Discount.

  • ChargeInformation inherits all properties from PriceModifier.

  • An OrderLine can have one or more ChargeInformation/DiscountInformation.

  • An Order can have one or more ChargeInformation/DiscountInformation.

Use case 5

o01NRUeCzWXK7VdhFr4SP4fJfjcvJuAx4IAAAAASUVORK5CYII=

  • The Delivery Party should not be the Despatcher role.

  • Semantically speaking, the delivery party should be the actual carrier.

  • In Denmark, the Beneficiary is the final delivery point.

  • From a PEPPOL point of view, in UBL the Delivery Party was mapped wrongly.

  • Updated the Additional Information section of the Beneficiary concept by adding the following: “In UBL/PEPPOL it is known as Delivery Party.”

  • Removed epo:dependsOnRole predicate at the epo:AgentInRole level.

All roles in 5 use cases in PEPPOL eOrdering are covered.

DeliveryInformation definition uses word parties that may need to be reconsidered depending on how party is defined in the ontology.

eOrdering meeting

Date: 20/10/2022
Participants: Pietro Palermo, Thomas Petterson, Ivan Willer
Model editor: Eugeniu Costetchi
Note editor: Natalie Muric

Agenda

AVDyZ3et6fRmAAAAAElFTkSuQmCC

  • The definition for epo-ord:Originator class was changed to:

The role of an agent that exploits the result of the procurement (service, goods or works).

Additional Information:
The beneficiary is also known as an end-user.
The agent playing the role of the beneficiary is often the same that plays the role of the originator.

WG approval: 20/10/2022

  • The definition for epo-ord:Consignee was changed to:

A role of an agent that receives the shipment of the procurement (service, goods or works) and who is taking possession.

Additional information:
The role is carried out by the customer or on behalf of the customer.
The possession of the goods does not necessary imply ownership.

(Consignee) Definition from PEPPOL Despatch:
The consignee is the person or organization to which the products will be shipped and who is taking possession. The role is carried out by the customer or on behalf of the customer.

WG approval: 20/10/2022

  • It was voted to omit mentioning the term "delivered".

  • Discussion regarding the Consignee role being part of the delivery party based on the following diagram::

8fQr34BVZfprgAAAAASUVORK5CYII=

The work done here has been on aligning the different terms used in different CEN TC 400 and therefore PEPPOL.

Use case eOrdering 1 from PEPPOL

  • Can only have one price in OrderLine in Italy, but in Sweden it can be 0 as it is in the catalogue.

  • epo-ord:Consignee is associated to epo-ord:DeliveryInstruction.

6MvQnzb1LVsAAAAASUVORK5CYII=

  • Despatch role is not needed in Order.

  • The discussion continued with going through all the roles needed.

    1. Order is triggered by Originator

    2. OrderLine is triggered by Originator

  • If several orginators are involved, they are mentioned at the OrderLine level.

  • If one originator is involved, it is mentioned at the Order level.

    1. Order is submitted by Buyer

    2. Order is submitted to Seller

    3. Delivery instruction is delivered to Consignee

    4. Delivery instruction is destined for Beneficiary

    5. Order is invoiced to invoicee

    6. Order is despatched by Despatcher (needed as can choose)

  • It is not clear yet if an invoicee is needed. It still remains the question if the invoicee is not always the buyer.

  • Carrier role is not needed in order.

eOrdering meeting

Date: 06/10/2022
Participants: Veit Jahns, Wim Kok, Pietro Palermo, Thomas Petterson, Victor Den Toom, Ivan Willer
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Discussing order only diagram.

Discussion

  • Order only diagram is based on PEPPOL use cases.

Use case 1 - Ordering of numbered items/articles

  • This use case contains an order of numbered items/articles.

x34BAAAAAASUVORK5CYII=

  • At the moment, the Price is at the OrderLine level.

  • The Price might be at the Item level and not at the Line level.

  • The justification for having the Price at the Line level is that we need to be able to track the price in the context of the catalogue and order.

  • It is preferred that the Price is at the Item level.

  • We can not defer to the decision made in the Catalogue module, so we should keep the Price at the Line level in order to be consistent.

  • In UBL Price is not mandatory, but what kind of order is without a Price.

  • Some Items are free and the Price is equal to 0.

  • Order Only is intended to be used with a catalogue.

  • An OrderLine can refer to a CatalogueLine.

    • Added new predicate epo-ord:refersToCatalogueLine [0..1] with Source epo:OrderLine and target epo:CatalogueLine.

    • The reference to the catalogue line is for information only, to trace the source of the information provided in the order line.

  • Adding a similar relation between Order and Catalogue, epo-ord:refersToCatalogue [0..1]

  • If we don’t refer to a catalogue, we should refer to a contract by using epo-cat:isSubordinatedToContract.

  • If an order refers to multiple catalogues then all these catalogues ideally are subordinated to the same contract.

  • One Invoice can refer to many Order/Contracts/Deliveries.

  • The epo-ord:OrderLine epo-ord:hasPlaceOfDelivery a dct:Location.

  • If multiple order lines refer to the same location, then the location object does not need to be replicated, but rather referred to by the different lines. Added a new class epo-ord:DeliveryInstruction:

B43IMyLWoYnaAAAAAElFTkSuQmCC

  • The name of the class should be revised and the definition added.

Action points

  • Discuss more on having the Price at the Item level rather than at the level of Line.

eOrdering meeting

Date: 08/09/2022
Participants: Ivan, Wim Kok, Pietro Palermo, Natalie Muric, Thomas Petterson, Giampaolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Roles in eOrdering versus eFulfilment.

Discussion

  • Continue discussing the Seller, Despatcher and Carrier roles.

  • Only epo-ord:Seller is part of eOrdering so this will be discussed today.

  • Maybe we do not need a epo-ord:Customer role.

  • We agreed not to make a distinction between a party and a Role:

    • A party can have multiple roles depending on the context.

    • A party is similar to a role.

Seller role

  • PEPPOL definition of epo-ord:Seller class:

    • ORDER: The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer.

    • DESPATCH: The seller is the legal person or organization who sells goods or services to the customer. The role is carried out by the supplier or on the behalf of the supplier.

    • INVOICE: One who issues an invoice for items or services sold to a Buyer and to whom a debt is owed. The Party that claims the payment and is responsible for resolving billing issues and arranging settlement.

    • Also known as Invoice Issuer, Accounts Receivable, Creditor, Economic operator.

  • The VAT Directive mentions that the Seller is the taxable person.

  • Added definition on epo-ord:Seller class: “Role of an agent who transfers the ownership of the procurement results (goods, services or work) to the Buyer.

Additional information:
A role of an agent that sells a procurement result (goods, services or work) to a Buyer.
The seller is bound by a contract i.e. it has legal responsibility.
The seller may or may not be the same as the supplier.
The seller may or may not issue the invoice.
The seller may or may not be the owner of the credit owed by the Buyer.

WG acceptance 08/09/2022”

  • In eProcurement Ontology:

    • An agent has identity over time independent of the context.

    • A role ties an agent to a part they play in a given situational context.

  • Do we have a Customer or a Supplier in the pre-award phase?

Supplier role

wAEcLbnc6rDIwAAAABJRU5ErkJggg==

  • Supplier role is out of discussion.

    • We do not care who provides these services or products. We care with whom business is done.

  • The Seller may be or may be not the Supplier.

  • epo-cat:Manufacturer should probably be renamed as Supplier.

    • Need to send a proposal to the eCatalogue team as well.

  • What are the difference between Supplier and a Seller:

    • Supplier is a Party, while the Seller is a Role/actor.

Invoicee role

  • Added definition: “A role of an agent to whom the invoice is addressed.

Additional information:
Often the invoicee is the Buyer.

In PEPPOL: A person or unit that receives the invoice (invoicee) on behalf of the customer.“

Invoicer role

  • Added definition: “The invoicer claims the payment and is responsible for resolving billing issues and arranging settlement.
    Alias: Invoicer“

  • There is a need to split all the roles into two parties:

    • Terms for left side: Demander, Requester, Initiator and Customer

    • Terms for the right side: Supplier, Provider

  • The next meeting will probably be in October.

eOrdering meeting

Date: 25/08/2022
Participants: Peter Borrensen, Cecile Guasch, Wim Kok, Pietro Palermo, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Roles in eOrdering versus eFulfilment.

Discussion

  • Trying to find an agreement between roles in order and fulfilment phases.

  • Definitions for roles can be also found on EESPA glossary.

epo-ord:Deliveree

  • Renamed to epo-ord:Consignee with the following definition: “A role of an agent that receives the products. ”

  • More info regarding the difference between shipment and consignment can be found on the OASIS documentation.

  • Contexts that use this role:

    • Ordering

    • Despatch

epo-ord:Originator

  • There is a distinction between Originator, Buyer and Beneficiary.

  • An Originator may not be the Beneficiary.

  • The Buyer may be or may be not the Originator.

epo-ord:Beneficiary

  • Added definition: “The role of an agent that exploits the result of the procurement (service, product or work).

Additional Information:
Alias: End-user

WG approval: 25/08/2022”

epo-ord:Orderer

  • This role is not needed since it is actually the Buyer.

epo:ProcurementOriginator

  • This should be deleted since it is not a proper role for this.

Discussion on Primary Roles vs Secondary Roles

  • There is a need to change the definitions for these two ePO classes.

JZB35nsjuGN04BbtXvWxLnVe1sSnmJePm7IpYpLStsfYgwMzzKWt4qQh9ubO1NW9dfbv8UiUncqA4PAU+RMoigkfiT1PRw4hYW4ejJK6vIfpje8Ypn+URUAAAAASUVORK5CYII=

epo-ord:Seller

  • The Seller may be the Supplier or may be not.

  • Discussing the difference between Seller and Supplier.

  • Supplier context:

    • Supply chain context

    • Does not need to own the goods it supplies.

  • Seller context:

    • Ownership goes from seller to the buyer.

    • Involved in the contract, is responsible for the trade.

  • The Supplier role is not important in the ordering and despatch phases. Only the Seller is.

  • Added definition: “A role of an agent who transfers the ownership of the procurement results (goods, services or works) to the Buyer.

Additional Information:
The seller is bound by a contract/order.”

epo-ful:Despatcher

  • Agreed on the existing definition for this role.

  • Discussing the difference between Despatcher and Deliverer.

  • This will be discussed in the next meeting.

Action Points

  • Address Role hierarchy.

eOrdering meeting

Date: 21/07/2022
Participants: Pietro Palermo
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • What is the scope of the eOrdering module? Which concepts and relations between them are covered here?

  • What sort of competency questions shall be answered? What shall be answered by the ontology?

  • What use cases, instance data examples, and application scenarios shall be considered?

Discussion

  • PEPPOL presentation

  • There are two sections, “order only” and “ordering”, which contain the response

  • When describing business term, it is bound to UBL syntax in

  • Main references:

Decisions

  • Meetings on Thursday from 14:30-16:30 EET

eOrdering kick-off meeting and scope definition

Date: 06/07/2022
Participants: Giorgia Lodi, Natalie Muric, Pietro Palermo
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • What is the scope of the eOrdering module? Which concepts and relations between them are covered here?

  • What sort of competency questions shall be answered? What shall be answered by the ontology?

  • What use cases, instance data examples, and application scenarios shall be considered?

  • What are the key experts to be consulted in this work?

  • What are the main materials to be consulted/considered?

  • What is the definition of done?

Discussion

  • TC440 work is going on and can be aligned to efforts in eProcurement ontology

  • Need:

    • to develop a data model that can be used in the transactions.

    • not a big data model, but something that works for the market

    • start with a core data model (that can be enlarged next year)

  • What is the definition of done?

    • All data information is necessary for their (TC440) transaction definitions.

  • What are the key experts to be consulted in this work?

    • Pietro /!\

  • What are the main materials to be consulted/considered?

    • In TC440 there are already specifications

  • What is the scope of the eOrdering module? Which concepts and relations between them are covered here?

    • Order is mostly about quantities of items (goods and services) and is linked to a catalogue.

    • Item identifier leads to a catalogue, and eOrdering will use that

    • Orders and Deliveries (request of delivery, not the actual delivery) are covered by the model

    • Time, place, price of delivery/order

    • Packaging is an important aspect of the eCatalogue

    • eCatalogue and eOrdering modules will be reused in the eInvoice module

    • Checking the performance in the supply chain

      • e.g. on delivery: order date vs delivery date

    • If there is a product that must be stored at a low temperature, then this kind of information must be specified in the order.

    • Some information about the item is critical for the transportation and preservation of the item (this info is possibly in the core or the extension)

    • The properties (relevant in the logistics) are specified in the Item (i.e in the eCatalogue)

    • The order MUST support the basic logistic process; Basic, not everything, of the logistics.

    • For example, insurance aspects can be covered in the eOrdering but only the basic, not the details.

    • For example, hazardous items need to be described and delivery information specified.

    • The contract is “something”, and the “order” is something else.

    • Main concepts:

      • Order

      • Parties

      • Expected delivery (time, place, receiver)

      • Accounting properties (price, tax, additional charges, )

      • Quantity totals (certain/final)

        • Amount is estimated (and may differ from what is delivered in the end)

        • “an ordered quantity” vs “delivered quantity” vs “invoiced quantity”

      • Monetary totals (estimated monetary values and the actual total will be put in the invoice)

        • Price (is not estimated, is fixed)

        • Additional costs related to the packaging, delivery, dispatch

      • Items (with IDs in some schema) and their classification

      • Additional properties of an Item (catalogue related) useful for people to Package, Deliver, Dispatch

      • We can try to profile properly the information that shall be in the catalogue, and in order.

  • What sort of competency questions shall be answered? What shall be answered by the ontology?

    • When, where and for what price was an item ordered? (not delivered, because the delivery is in the eFulfillment)

    • Which group of items have been ordered by a “buyer” from a “seller”?

    • What is the expected delivery date and place (not the actual one)?

    • Who will receive the order (i.e. the consignee)?

  • The work methodology:

    • GitHub Issues

    • Regular meetings (x2 Wednesdays and then every 2nd Thursday)

  • What are the main materials to be consulted/considered?

  • /!\ Warning: We shall try and keep it as small as possible. eOrder may be one of the largest areas in the post-award.